home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / standards / ansi / X3T9 / area13 / u9001044.txt < prev    next >
Encoding:
Text File  |  1992-05-12  |  8.7 KB  |  169 lines
  1. This is one of the old Unix-OSD Group Messages that John Gallant sent to me
  2. for posting on the SCSI BBS.  The date reflects when he sent it to me, not
  3. the original message date.  John Lohmeyer
  4. ----------------------------------------------------------------------------
  5.  
  6. Date: Thu, 4 Jan 90 17:16:01 -0500
  7. From: "John A. Gallant UEG" <jag@decvax.dec.com>
  8. Message-Id: <9001042216.AA25681@abyss.zk3.dec.com>
  9. To: jlohmeye@entec.wichita.ncr.com
  10. Subject: re: Darryl's Unix OSD document
  11.  
  12.  
  13.  
  14. jag@decvax.dec.com writes:
  15. "darryl@ism780c.isc.com writes:
  16. ">       6.5  UNIX_Operating_System
  17. ">[...]
  18. ">       At kernel configuration and link time, a static table of
  19. ">       included peripheral drivers and SIMs is created and linked
  20. ">       into the configuration driver.
  21. "    A static table is definitly needed for the configuration/XPT/SIM points.
  22. "They are going to need knowledge of how to contact one another in a non link
  23. "time manor.  However a problem with the peripheral drivers will occur when
  24. "you have BSD based systems vs system V.  It probably will be good to have 
  25. "entry/or other points for the drivers within this table.  Perhaps a default
  26. "call back or fatal error entry point, or simply a reset/restore point, I'm
  27. "not sure just what at this time.
  28.  
  29. I'd prefer to see that the table be kept simple, but if that is not possible,
  30. I'd like to have the simple part of it mandatory and let vendors specify
  31. optional extras.  They own the configuration driver and XPT anyhow.
  32.  
  33. ">       6.5.1  Initialization
  34. ">
  35. ">       At system startup, the configuration driver's init function
  36. ">       is run from the ioinit array.  .......................
  37. "    With BSD based there no "ioinit" array, I belive that this is a sys V
  38. "concept, where there is one init routine per driver.  In BSD systems there
  39. "are the triplet routines probe/attach/slave.  These are called via the
  40. "configuration magic higher up in the Kernel.
  41.  
  42. Pardon me.  I must admit to having little knowledge of the internals of BSD,
  43. and I'm sure that my Sys V experience is showing where it was not intended.
  44. Because of this, perhaps it would help if you could give a brief overview
  45. of the init time actions in a BSD kernel;  to make it fair, here's a quick
  46. description of Sys V:
  47.  
  48. After booting, the kernel enters main().  Interrupts are disabled at this
  49. point.  When the kernel was linked, two tables of routines were created:
  50. io_init[] and io_start[].  (These are constructed mechanically by idconfig,
  51. which looks into the mdevice file for each driver and determines if it has
  52. an init and/or start routine, and builds the names as "prefix"init and
  53. "prefix"start, from the "prefix" specified in mdevice.)  The entries are
  54. in mdevice file order, but I don't think that there's any guarantee that
  55. will always be true.  While interrupts are off, each entry in the io_init[]
  56. array is called.  Then interrupts are turned on, some copyright stuff is
  57. printed, and each routine in io_start[] is called.  After this point, normal
  58. operation is expected.
  59.  
  60. ">       .............................  It calls across the CAM
  61. ">       interface, through the XPT, to each SIM in turn, allowing
  62. ">       them to initialize.  The configuration driver obtains
  63. ">       information about each SIM, HBA, and target device detected
  64. ">       and maintains a table of these devices.  Note that
  65. ">       interrupts are disabled during the ioinit phase.
  66. "    I would expect them to be turned off during all the setup and init phases.
  67.  
  68. Yes.  Also, we should reword these paragraphs so that io_init is not used.
  69. We need to come up with some terminology that satisfies both Sys V and BSD.
  70. Can you suggest something, John?
  71.  
  72. ">       After all of the SIMs have initialized and the configuration
  73. ">       table has been filled in, the configuration driver invokes
  74. ">       the initialization routines for each peripheral driver.
  75. ">       This allows them to determine what devices are known and
  76. ">       make appropriate memory allocations and resource requests of
  77. ">       the XPT.
  78. "    This is were the I have the biggest problem.  With BSD based systems
  79. "the configuration magic sets up a number of data structures that are
  80. "used by a lot of the io/fs utilities.  Would this mean that these BSD based
  81. "systems would have to minic what the conf code is doing in the
  82. "configuration/XPT init handlers ?
  83.  
  84. I don't see that it is necessary since the configurator will have all the
  85. knowledge that was necessary to construct the driver/SIM table.
  86.  
  87. "    I think that what we had originaly discussed back in November(?), is
  88. "still valid.  The plan was that the first call to the XPT to initialize
  89. "itself from any peripheral driver would kick off the configuration
  90. "driver/XPT/SIM sequence.  Once the sequence had finished that initial
  91. "call from the peripheral driver would be completed.  Using the ioinit[]
  92. "array scheme the first call would come from the configuration driver.
  93. "In the BSD/configuraion scheme, the sequence of what peripheral drivers
  94. "is called before another is not known, so any peripheral driver could be
  95. "called before the configuration driver. 
  96. "
  97. "    I know that this is a little complicated but it does remove any
  98. "constraints on a predefined initialization sequence.
  99.  
  100. I'm not sure I understand exactly what distinction you are trying to make
  101. here.  The two proposals look very similar in functionality.  I chose
  102. mine because I wanted to make the configuration driver available as a
  103. separate entity that would be available to do dynamic loading and unloading
  104. of drivers.  Perhaps it is my Sys V myopia again, but I had intended that
  105. none of the other drivers or SIM modules would be called out of the ioinit[]
  106. array;  instead, by giving responsibility for the whole subsystem's
  107. initialization to the configuration driver, we can also gain some control
  108. and order the initialization process, if that is useful.  For example, when
  109. performing an installation on a PC, I might want to ignore most devices
  110. and concentrate on my root disk;  I could use the configuration driver to
  111. control this.
  112.  
  113. ">       6.5.2  Accessing_the_XPT
  114. "> [...]
  115. ">       6.5.2.2  From_the_SIM
  116. ">
  117. ">       The SIMs obtain requests from the XPT as they are passed
  118. ">       across from the peripheral driver, via a routine included in
  119. ">       the SIM's configuration information.  The field in the
  120. ">       configuration table is declared as
  121. ">       void (* SIMaction)(CCB *).  The XPT does not modify ccbs or
  122. ">       cdbs.  The XPT must intercept those ccbs which must be 
  123. ">       redirected to the configuration driver (i.e., Path Inquiry,
  124. ">       Get Device Type, and Set Device Type).
  125. "    What worries me is that we have spent a lot of work making sure that the
  126. "SIMs do not have to worry about what is contained in a CDB.  Now we have the
  127. "XPT scanning each CCB for particular commands that need to be routed to 
  128. "another driver, even though the configuration driver "works for the XPT".
  129. "Unfortunatly I don't have another way to handle this problem.  I do however 
  130. "have an possible way to make the interception of CCBs a little simpler.
  131. "What about having the commands that are particular to the configuration driver/
  132. "XPT be within a range of values or have a particular bit, msb, set to signify
  133. "special routing is needed.
  134. "
  135. "    This may be too much work considering that we only have about 7 commands, 
  136. "but what if the list gets much larger ?  How many cascading if() statements
  137. "become too many ? Or how many angels can dance on the head of a pin .. ? Oops
  138. "sorry I became carried away :-).
  139.  
  140. 42.  ;-)  Surely a table of routing codes could reduce the cost to O(1)
  141. in checking for CAM commands vs. SCSI commands.
  142.  
  143. ">       6.5.3  Callback_on_Completion
  144. ">
  145. ">       The callback field in the ccb is a structure that is
  146. ">       platform specific, but always contains at least a callback
  147. ">       function pointer, named cbfcnp, and declared as
  148. ">       void (*cbfcnp)(CCB *).  It is allowed for the cbfcnp to
  149. ">       contain NULL, in which case no callback operation is
  150. ">       performed.
  151. "
  152. "   Do we want to look at what the SIM does after the CCB is complete?  I would
  153. "expect that it would handle the next CCB on its queue.  But what if its queue
  154. "is empty, do we want it to call back to the XPT to allow another SIM to do
  155. "something ?  Or would it be better to have each SIM only handle its particular
  156. "queue, and have the other SIMs on interrupts handle theirs?  Could we get into
  157. "a dead lock condition where everybody is waiting for an event to start off
  158. "their queue ?
  159.  
  160. This is an important point.  For good performance, the SIM must give up
  161. control quickly after completing a CCB;  otherwise it is possible to
  162. hog the system for one HBA over others.  As far as deadlock goes, the
  163. SIM is responsible for watching the timeout value for each CDB.  This may
  164. require it to set a callout routine for the minimum timeout value in its
  165. queue.
  166.  
  167.         --Darryl Richman
  168.  
  169.